Bump ktir-mlir-frontend past the ktdp.memory_space rename - #108
Conversation
Moves the submodule from 973d67e to 05e7a0f (4 commits), whose tip is "Source structure refactoring (issue torch-spyre#37) (torch-spyre#46)". That refactor relocates the KTDP public headers, so every consumer here needs its includes rewritten: Ktdp/KtdpOps.hpp -> ktir/Dialect/KTDP/KTDP.h Ktdp/KtdpDialect.hpp -> ktir/Dialect/KTDP/KTDPDialect.h Ktdp/KtdpAttrs.hpp -> ktir/Dialect/KTDP/KTDPAttrs.h Ktdp/KtdpTypes.hpp -> ktir/Dialect/KTDP/KTDPTypes.h No CMake change is needed: add_ktir_library still sets EXPORT_NAME KtdpDialect and _install_ktir_library still creates the KTIR::KtdpDialect alias, so existing link lines resolve unchanged. The LLVM pin (cmake/llvm-hash-spyre.txt, e9846648) is identical on both sides, so no LLVM rebuild is implied. The `groups`-folded-into-!ktdp.tile_future syntax change was already present at the previous pin and the lit expectations here already match it, so no test updates were required. Verified: spyre-triton-opt builds clean against the Spyre LLVM, and the lit suite passes 34/34. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Yu Chin Fabian Lim <flim@sg.ibm.com>
…turing triton_spyre.cc was missed by the include rewrite in 9c3084c: it is a .cc file, and the sweep that found the other seven consumers only matched .cpp/.h. It is compiled into libtriton rather than spyre-triton-opt, so the lit-only verification in that commit did not cover it — the failure surfaces on `uv pip install -e .` as: triton_spyre.cc:10:10: fatal error: 'Ktdp/KtdpDialect.hpp' file not found Verified: the editable install now builds libtriton clean and `import triton` resolves to this checkout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Yu Chin Fabian Lim <flim@sg.ibm.com>
Moves the submodule 05e7a0f -> ed069fb6, picking up three commits:
3da565b [Ktdp] Add KtirCheckLegality pass stub
a3d6bd1 Remove KtdpMemorySpaceAttr interface, replace
ktdp.spyre_memory_space with ktdp.memory_space
ed069fb Add the `spyreop` dialect (torch-spyre#57)
a3d6bd1 is a breaking change and the reason for this bump. It is not just a
rename — the attribute's enum changed meaning:
old: #ktdp.spyre_memory_space<HBM> kind enum {unspecified, LX, HBM}
new: #ktdp.memory_space<global> kind enum {global, ct_local}
and the C++ parameter `value` became `kind`, with `core` becoming the optional
`ct_id`. Following upstream's own migration of test/Dialect/KTDP/add.mlir,
HBM maps to `global`.
Changes here:
- two C++ construction sites (LowerDescriptorMemory, LowerScalarLoad):
SpyreMemorySpaceAttr/SpyreMemorySpaceKind::HBM -> MemorySpaceAttr/
MemorySpaceKind::global
- 18 .mlir test files, 187 occurrences, all the single form
spyre_memory_space<HBM> -> memory_space<global>
Nothing here referenced the deleted KTDPAttrInterfaces.h, so no include
changes were needed beyond those already made for the source restructuring.
Verified: spyre-triton-opt builds clean; lit 34/34; pytest 1146 passed,
47 skipped, 0 failed (the 3 inter_tile_reduce numerical failures present at
the previous pin are also resolved).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Yu Chin Fabian Lim <flim@sg.ibm.com>
Do not merge yet — two temporary pins to revert firstCI is green, but only because this branch points at two unmerged refs. Both must be repinned before merge, in this order: 1. torch-spyre/ktir-cpu#208 — the matching ktir-cpu migration ( Once it merges, revert "ktir-cpu @ git+https://github.com/torch-spyre/ktir-cpu@main",The original line is kept inline as a comment in 2. torch-spyre/ktir-mlir-frontend#59 — the Worth noting for #59: this branch is what surfaced that bug. Current CI state
Matches local results exactly, so nothing is being masked by the temporary pins — they only change where the dependencies come from, not what is tested. |
Update: both PRs green — and the revert list is three pins, not twoCI is now passing on both sides:
Correcting my note above: there are three temporary pins to unwind, not two. The third is inside ktir-cpu#208. After torch-spyre/ktir-mlir-frontend#59 merges:
After ktir-cpu#208 merges: revert Why #59 alone did not unblock ktir-cpuWorth recording, since it is easy to hit again. #59 pins ktir-cpu's CI installs with Not included here, deliberatelyAn earlier revision of ktir-cpu#208 widened two regexes in the MLIR frontend so rank-0 |
Advances the submodule ed069fb6 -> ecfb9ed, picking up torch-spyre/ktir-mlir-frontend#59 ("Pin cmake>=4.0 and enable stubgen in CI"). This is what unblocks CI. `05e7a0f` (already in this branch's range) added `MLIR_PYTHON_STUBGEN_ENABLED = "ON"` to the submodule's pyproject.toml, which activated a latent overflow: MLIR's `mlir_generate_type_stubs()` builds a 283-char target name by joining DEPENDS_TARGETS, and CMake 3.x writes that full name into its file-API reply filename, overflowing NAME_MAX (255). The bindings install then died with ENAMETOOLONG — errno 63 locally on macOS, errno 36 in CI on Linux. torch-spyre#59 pins cmake>=4.0 in build-system.requires; CMake 4.0 truncates the name and relies on the trailing hash, so stubgen stays enabled rather than being worked around here. Note that pin only applies to an isolated PEP 517 build — a consumer running cmake directly is unaffected (the project itself declares cmake_minimum_required(VERSION 3.21)), and the cmake it installs lives only in the ephemeral build environment. ecfb9ed is the squashed commit on ktir-mlir-frontend main, so this is no longer a pin to an unmerged branch head. Signed-off-by: Yu Chin Fabian Lim <flim@sg.ibm.com>
2 participants
Bumps
ktir-mlir-frontendfrom973d67etoed069fb6(upstreammain) and adapts this repo to two breaking changes in that range.The motivating change is
a3d6bd1, which replacesktdp.spyre_memory_spacewithktdp.memory_space. Getting past that rename is the point of this PR; the source restructuring came along the way and is split into its own commit.Commits
9c3084c505e7a0f; adapt to source restructuring (7 files)58fdedd5triton_spyre.cc85f36260ed069fb6; migrate offktdp.spyre_memory_space(20 files)Reviewing commit-by-commit is easier than the squashed diff — the first two are pure include-path moves, the third is the semantic change.
1. Source restructuring (
05e7a0f)KTDP's public headers moved, so every consumer needs its includes rewritten:
No CMake change was needed:
add_ktir_librarystill setsEXPORT_NAME KtdpDialectand_install_ktir_librarystill creates theKTIR::KtdpDialectalias, so existing link lines resolve unchanged.triton_spyre.ccis a separate commit because it was missed initially — it's a.ccfile, and it compiles intolibtritonrather thanspyre-triton-opt, so a lit-only check can't catch it. Worth remembering for the next bump.2.
spyre_memory_space→memory_space(a3d6bd1)Not just a rename — the attribute's enum changed meaning:
The C++ parameter
valuebecamekind, andcorebecame the optionalct_id.HBMmaps toglobal— taken from upstream's own migration oftest/Dialect/KTDP/add.mlirrather than inferred, since the two enums don't correspond term-by-term. If that mapping is wrong for a Spyre-specific reason, this is the commit to revisit.Changes:
LowerDescriptorMemory,LowerScalarLoad).mlirtest files, 187 occurrences, all the single formspyre_memory_space<HBM>Nothing here referenced the deleted
KTDPAttrInterfaces.h.Also in this range
3da565b—KtirCheckLegalitypass stubed069fb— thespyreopdialect, which unblocks [Discussion] Recognize arith/math patterns and lower them to spyreop intrinsics #107. Nothing in this repo emits those intrinsics yet; this bump just makes them available.Testing
spyre-triton-optbuilds clean against the Spyre LLVMThe 3
inter_tile_reducenumerical failures that were present before this PR are also resolved — they were stale bindings, not a code issue.